Итак, моя главная цель в техно-некромантии на ближайшее время — научиться писать свой собственный софт под древнюю операционную систему GRiD OS, которая работала на ноутбуках GRiD Compass в начале-середине 80-х годов.
И это не так просто, как может показаться, потому что инструменты разработки ПО для GRiD OS — это крайне древний и редкий артефакт, и обрести его непросто. Его нет в Интернете, его нет в архивах Интернета, оно и понятно — мы говорим об артефакте из времени, когда Интернета, по сути, не было. Обычно у техно-некроманта в таких случаях остаётся всего два пути: клянчить артефакт у некромантов повыше левелом, либо крафтить его самостоятельно путём реверс-инжиниринга. Я не знаю, какой из этих путей приведёт к успеху, поэтому я решил действовать по всем направлениям сразу. И сейчас расскажу, какой на данный момент сделан прогресс.
Начнём с поиска готовых инструментов разработки. Древние манускрипты повествуют о том, что где-то в этом мире существует инструмент GRiDDevelop — готовая среда разработки ПО, что-то вроде современных IDE. Она позволяет редактировать, компилировать и линковать код проектов, поддерживает несколько языков программирования — C, ASM, Fortran, Pascal и PL/M (слышали о таком?).
Спустя какое-то время я смог найти GRiDDevelop, и даже смог запустить его на эмуляторе, но оказалось, что сама по себе эта утилита не умеет ничего — она выступает в роли «клея», соединяя вместе текстовый редактор, компиляторы, линковщики и системные библиотеки. И ничего из этого мне не удалось обнаружить.
Тем не менее, мне удалось связаться с некромантом 80 уровня, который последние несколько лет покупал на eBay внешние жёсткие диски для компьютеров GRiD Compass в поисках интересных файлов, и в итоге ему удалось найти и собрать полный набор инструментов разработки, включая системные библиотеки, заголовочные файлы, компиляторы, документацию и т.д:
И мне удалось связаться с этим человеком! Ответил он мне буквально вчера. Однако он ещё более занятой, чем я, так что неизвестно, когда я смогу получить копию этих инструментов разработки, и смогу ли вообще в обозримом будущем.
Более того, остаётся открытым вопрос, смогу ли я запустить эти инструменты — для их корректной работы требуется машина с 512к оперативки (в Compass 1101, который сейчас находится у меня, их всего 256), и внешний жёсткий диск на 10 мб (в обозримом будущем вряд ли у меня появится). Опять же неизвестно, заработает ли этот софт под эмулятором.
Поэтому параллельно с поиском готового набора инструментов разработки я работаю над другим планом — реверс-инжиниринг бинарников для GRiD OS. В теории, если разобраться в формате заголовка исполняемого файла, можно будет создавать свои собственные рабочие бинарники. А если внутри исполняемого файла отыскать код и разобраться в том, как он работает, можно будет написать свою реализацию некоторых «библиотечных» или «системных» функций, и использовать это при написании готового софта. Но для начала необходимо получить в своё распоряжение несколько образцов программ под GRiD OS для изучения. Задача непростая — весь доступный сегодня софт под GRiD OS существует в виде образов дискет, при этом файловая система у GRiD своя собственная, и эти образы никакими существующими утилитами не читаются.
И здесь нас здорово выручили ребята из, внезапно, NASA. В 2003 году они выложили в открытый доступ свою систему SPOC — ту самую, которая стояла на ноутбуках GRiD, летавших в космос на Шаттлах. Что ещё интереснее, в более поздние годы эта система работала на компьютерах GRiDCase, поверх MS-DOS — и в открытый доступ попала именно эта версия. Она состоит из образа загрузочной MS-DOS дискеты, на которой так же находится утилита InteGRiD — по сути, эмулятор GRiD OS, и, помимо неё, оригинальный SPOC, собранный под GRiD OS. Кому интересно, может скачать готовую Virtualbox виртуалку здесь — https://github.com/robertely/SPOC-VirtualBox
Что нам это даёт? Мы получаем доступ к бинарникам GRiD OS, записанным на файловую систему FAT, которую мы можем легко распаковать и получить доступ к индивидуальным файлам:
К сожалению, из бинарников, обнаруженных в этом образе, было понятно чуть менее, чем ничего. Файлы весили по 10-20 килобайт, у них был непонятный заголовок, неизвестно как вычисляемый адрес точки входа, и очень странное перемешивание кода и данных. Поэтому я задался целью найти самый маленький бинарник под GRiD OS и начать с него. И для этого пришлось заняться изучением образов дискет более плотно.
Как я уже писал, GRiD OS использует свою собственную файловую систему. Гугление показало, что она чем-то похожа на UNIX v6 filesystem, но не совсем, поэтому открыть образы дискет GRiD OS сегодня просто нечем. Дискету в таком формате можно открыть либо на GRiD Compass, либо на MS-DOS устройстве с InteGRiD. Попробовав открыть образ на эмуляторе через InteGRiD, я смог увидеть список файлов, но не смогу ничего прочитать — столкнулся с «неожиданной ошибкой диска №108», так что у меня не осталось другого выбора кроме как разреверсить файловую систему.
Поизучав некоторое время образы дискет с помощью hex-редактора, калькулятора и jupyter notebook-а, я примерно разобрался в том, как в ней записаны файлы. Файловая система разбита на блоки по 512 байт, каждый блок начинается с номера блока. В некоторых блоках записана информация о файле — его имя, размер, версия и список блоков, в которых лежат куски этого файла. Директория в этой файловой системе представляет собой такой же файл, в котором перечислены имена хранящихся в директории файлов и адреса блоков с их описанием. Существует «суперблок» — блок с описанием корневой директории, с которого и следует начинать чтение образа файловой системы. Вот так вкратце обстоят дела. В общем, ничего особо сложного, поэтому я оформил свои поскриптушки в jupyter notebook в полноценную тулзу на сях (до сих пор не могу понять, почему выбрал именно си, настрадался же вроде уже), которая позволяет вывести содержимое образов дискет в формате GRiD OS, и сдампить файлы из этих образов.
Запаковка файлов обратно в образ пока не поддерживается, ибо я до сих пор не понимаю назначение некоторых полей в файловой системе. Но даже сейчас от этой утилиты есть толк: распаковав нужные мне файлы, я могу запускать их в Virtualbox из-под InteGRiD. Например, мне наконец-то удалось найти GRiDBasic, и он даже запустился (см. ниже), но увы, под двойной эмуляцией (InteGRiD + Virtualbox) он не смог нормально работать и упал при попытке посчитать 2+2:
Зато распаковка кучи образов позволила мне найти самый маленький бинарник под GRiD OS, который весил всего лишь 751 байт, 290 из которых занимали разные строки, и ещё около сотни — заголовок.
Промазать здесь с точкой входа было тяжело, весь код занимает от силы 200 байт, но его декомпиляция преподнесла неприятный сюрприз:
Весь код состоит из последовательного запихивания в стек разных значений, и последующего вызова прерывания 0x70. Затем выходное значение сравнивается с чем-нибудь, и всё повторяется вновь. Очевидно, это вызовы каких-то системных функций ОС, но где найти их реализацию и как понять, какой вызов что делает? Было бы неплохо хотя бы понять формат этого вызова: где здесь номер функции, а где её параметры?
И здесь на помощь неожиданно приходит архив, в котором я обнаружил GRiDDevelop. В нём же обнаружились… Исходники InteGRiD! На асме, правда, так что да, разбираться немного сложно. Тем не менее, мы понимаем, что если кто-то вызывает int 0x70, то где-то в коде эмулятора обязательно должен быть обработчик этого прерывания — иии да, он там действительно есть:
К сожалению, я в асме не так хорош, чтобы во всём этом быстро разобраться, но в исходниках InteGRiD однозначно есть таблица с реализацией различных системных функций:
Сопоставив параметры в дизассемблированном коде GRiD OS утилит с таблицей системных функций и их параметров, мы сможем лучше понять, что происходит в коде той или иной утилиты, и сможем сами писать код, вызывая те или иные функции ОС в нём.
На данный момент это всё, что я знаю. Дальше я пока не зашёл. Чтобы в этом разобраться, потребуется ещё огромное количество времени и усилий, эту заметку я написал скорее не для того, чтобы похвастаться результатами, а для того, чтобы не забыть текущий прогресс, когда я рано или поздно вернусь к этой теме. Но старт положен, мы знаем, куда двигаться, и нас уже не остановить :) Если у вас есть знания в асме и реверс-инжинеринге, и вам тоже будет интересно в этом разобраться — пишите, попробуем осилить это вместе!